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Transmission of Syslog Messages over TCP 
Abstract 


There have been many implementations and deployments of legacy syslog 
over TCP for many years. That protocol has evolved without being 
standardized and has proven to be quite interoperable in practice. 
This memo describes how TCP has been used as a transport for syslog 
messages. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for the historical record. 


This document defines a Historic Document for the Internet community. 
This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6587. 


IESG Note 


The IESG does not recommend implementing or deploying syslog over 
plain tcp, which is described in this document, because it lacks the 
ability to enable strong security [RFC3365]. 


Implementation of the TLS transport [RFC5425] is recommended so that 
appropriate security features are available to operators who want to 
deploy secure syslog. Similarly, those security features can be 
turned off for those who do not want them. 
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Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The Standards-Track documents in the syslog series recommend using 
the syslog protocol [RFC5424] with the TLS transport [RFC5425] for 
all event messages. The authors of this document wholeheartedly 
support that position and only offer this document to describe what 
has been observed with legacy syslog over TCP, which appears to still 
be widely used. 


Two primary format options have been observed with legacy syslog 
being transported over TCP. These have been called "non-transparent-— 
framing" and "octet-counting". The non-transparent-framing mechanism 
has some inherent problems. 


Diagram 1 shows how all of these syslog transports relate to each 
other. In this diagram, three originators are seen, labeled A, B, 
and C, along with one collector. Originator A is using the TCP 
transport that is described in this document. Originator B is using 
the UDP transport, which is described in [RFC5426]. Originator C is 
using the TLS transport, which is described in [RFC5425]. The 
collector is shown with the capability to accept all three 
transports. 
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Diagram 1. Syslog Layers 
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3e 


Conventions Used in This Document 
The terminology defined in Section 3 of [RFC5424] is used throughout 
this specification. The reader should be familiar with that to 


follow this discussion. 


This document also references devices that use the syslog message 


format as described in [RFC3164]. Devices that continue to use that 
message format (regardless of transport) will be described as "legacy 
syslog devices". Similarly, devices that use the message format as 


described in [RFC5424] will be described as "Standardized syslog 
devices". 


Message Transmission 


Syslog is simplex in nature. It has been observed that 
implementations of syslog over TCP also do not use any back-channel 
mechanism to convey information to the transport sender and, 
consequently, do not use any application-level acknowledgement for 
syslog signaling from receiver to sender. Message receipt 
acknowledgement, reliability, and flow control are provided by the 
capabilities of TCP. 


1. Character Encoding Scheme 


Syslog over TCP messages contain no indication of the coded character 
set (e.g., [US-ASCII] or [UNICODE] ) or character encoding scheme 
(e.g., so-called "7-bit ASCII" or UTF-8 [RFC3629]) in use. In these 
messages, the predominant approach has been to include characters 
only from the ASCII repertoire (i.e., %d32 to %d126 inclusive) using 
the "Network Virtual Terminal" (NVT) encoding [RFC5198]. 


The message header usually contains characters only from the ASCII 
repertoire, in the NVT encoding. This has been observed even in 
cases where a different encoding (e.g., UTF-8) has been used for the 
MSG part. However, characters outside the ASCII range have been seen 
inside the header. In that case, some syslog applications have been 
known to experience problems processing those messages. 


In some cases, it has been observed that characters outside of the 
ASCII range are often being transformed by receivers in an effort to 
"escape control characters". Some receiver implementations simply 
drop those characters. This is considered to be a poor practice, as 
it causes problems with coded character sets other than ASCII and 
character encodings other than NVT, most notably the UTF-8 encoding 
of Unicode. 
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It has also been observed that relays will forward messages using the 
character encoding schemes of messages they receive. In the case 
where two different senders are using different character encoding 
schemes, the relay will forward each message to a collector in that 
character encoding. The collector of these messages will have to be 
prepared to receive messages from the same relay with different 
encodings. 


3.2. Session 


Like most other protocols, the syslog transport sender is the TCP 
host that initiates the TCP session. After initiation, messages are 
sent from the transport sender to the transport receiver. No 
application-level data is transmitted from the transport receiver to 
the transport sender. The roles of transport sender and receiver 
seem to be fixed once the session is established. 


When it has been observed, if an error occurs that cannot be 
corrected by TCP, the host detecting the error gracefully closes the 
TCP session. There have been no application-level messages seen that 
were sent to notify the other host about the state of the host syslog 
application. 


3.3. Session Initiation 


The TCP host acting as a syslog transport receiver listens to a TCP 
port. The TCP transport sender initiates a TCP session to the syslog 
transport receiver as specified in [RFC0793]. 


This protocol has no standardized port assignment. In practice, 
network administrators generally choose something that they feel will 
not conflict with anything else active in their networks. This has 
most often been either TCP/514, which is actually allocated to 
another protocol, or some variant of adding 514 to a multiple of 
1000. Please see Section 4 for more information. 


3.4. Message Transfer 


Syslog over TCP has been around for a number of years. Just like 
legacy syslog over UDP, different implementations exist. The older 
method of non-transparent-framing has problems. The newer method of 
octet-counting is reliable and has not been seen to cause problems 
noted with the non-transparent-framing method. 


In both of these methods, during the message transfer phase, the 


syslog transport sender sends a stream of messages to the transport 
receiver. These are sent in sequence and one message is encapsulated 
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3; 


inside each TCP frame. Either of the TCP hosts may initiate session 
closure at any time as specified in Section 3.5 of [RFC0793]. In 
practice, this is often seen after a prolonged period of inactivity. 


4.1. Octet Counting 

This framing allows for the transmission of all characters inside a 
syslog message and is similar to the method used in [RFC5425]. A 
transport receiver uses the defined message length to delimit a 
syslog message. As noted in [RFC3164], the upper limit for a legacy 
syslog message length is 1024 octets. That length has been expanded 
for standardized syslog. 


It can be assumed that octet-counting framing is used if a syslog 
frame starts with a digit. 


All syslog messages can be considered to be TCP "data" as per the 
Transmission Control Protocol [RFC0793]. The syslog message stream 
has the following ABNF [RFC5234] definition: 

TCP-DATA = *SYSLOG-FRAME 


SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG ; Octet-counting 
; method 


MSG-LEN = NONZERO-DIGIT *DIGIT 
NONZERO-DIGIT = %d49-57 


SYSLOG-MSG is defined in the syslog protocol [RFC5424] and may 
also be considered to be the payload in [RFC3164] 


MSG-LEN is the octet count of the SYSLOG-MSG in the SYSLOG-FRAME. 


-4.2. Non-Transparent-—Framing 


The non-transparent-—framing method inserts a syslog message into a 
frame and terminates it with a TRAILER character. The TRAILER has 
usually been a single character and most often is ASCII LF (%d10). 
However, other characters have also been seen, with ASCII NUL (%d00) 
being a prominent example. Some devices have also been seen to emit 
a two-character TRAILER, which is usually CR and LF. 


The problem with non-transparent-—framing comes from the use of a 
TRAILER character. In that, the traditional TRAILER character is not 
escaped within the message, which causes problems for the receiver. 
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For example, a message in the style of [RFC3164] containing one or 
more LF characters may be misinterpreted as multiple messages by the 
receiving syslog application. 


The ABNF for this is shown here: 
TCP-DATA = *SYSLOG-FRAMFE 


SYSLOG-FRAME = SYSLOG-MSG TRAILER ; non-transparent-—framing 
; method 


TRAILER = LF / APP-DEFINED 
APP-DEFINED = 1*20CTET 


SYSLOG-MSG is defined in the syslog protocol [RFC5424] and may 
also be considered to be the payload in [RFC3164] 


A transport receiver can assume that non-transparent-framing is used 
if a syslog frame starts with the ASCII character "<" (%d60). 


3.4.3. Method Change 


In legacy implementations, it has been observed that the framing may 
change on a frame-by-frame basis. This is probably not a good idea, 
but it’s been seen. 


3.5. Session Closure 


The syslog session is closed when one of the TCP hosts decides to do 
so. It then initiates a local TCP session closure. Following TCP 
[RFC0793], it doesn’t need to notify the remote TCP host of its 
intention to close the session, nor does it accept any messages that 
are still in transit. 


4. Applicability Statement 


Again it must be emphasized that the Standards-Track documents in the 
syslog series recommend using the TLS transport [RFC5425] to 
transport syslog messages. This document does not recommend that new 
implementations or deployments use syslog over TCP except for the 
explicit purpose of interoperating with existing deployments. 


One of the major problems with interoperability with this protocol is 
that there is no consistent TCP port assigned. Most of the 
successful implementations have made the selection of a port a user- 
configurable option. The most frequently observed port for this has 
been TCP/514, which is actually assigned to the Shell protocol. 
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Operators must carefully select which port to use in their deployment 
and be prepared to encounter different default port assignments in 
implementations. 


There are several advantages to using TCP: flow control, error 
recovery, and reliability, to name a few. These reasons, and the 
ease of programming, have led people to use this transmission 
protocol to transmit syslog. 


One potential disadvantage is the buffering mechanism used by TCP. 
Ordinarily, TCP decides when enough data has been received from the 
application to form a segment for transmission. This may be adjusted 
through timers; but still, some application data may wait in a buffer 
for a relatively long time. Syslog data is not normally time- 
sensitive, but if this delay is a concern, the syslog transport 
sender may utilize the PUSH Flag as described in [RFC0793] to have 
the sending TCP immediately send all buffered data. 


5. Security Considerations 
This protocol makes no meaningful provisions for security. It lacks 
authentication, integrity checking, and privacy. It makes no 


provision for flow control or end-to-end confirmation of receipt, 
relying instead on the underlying TCP implementations to approximate 
these functions. It should not be used if deployment of [RFC5425] on 
the systems in question is feasible. 
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